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A Controller Area Net- 
work obviously con- 
sists of more than 
just the CAN bus 
interface 
described in last 
month’s instalment of 
this article. In fact, the 
interface is merely the 
link between a 
microcontroller or 
computer and the 
CAN bus proper. The 
hardware described 
in detail last month 
clearly needs soft- 
ware for its proper 
Operation and this is 
described in this 
fourth instalment of 
the article. 


By B vom Berg & P Groppe 
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INTRODUCTION 

Each station or node in a CAN bus sys- 
tem needs, apart from the CAN Bus 
Interface, a microcontroller or com- 
puter with appropriate software. Two 
sets of software are needed for taking 
the station into use, test it, and oper- 
ate it: operating software and applica- 
tions software. 

The operating software is needed 
to provide an effective overall system, 
and also to test the interface in associ- 
ation with the microcontroller or com- 
puter. Such a test shows whether or 
not the drive from the microcontroller 
or computer functions correctly, 
whether or not the interface works 
correctly, both from a hardware and a 


software point of view, and whether 
the data is transferred correctly onto 
the CAN bus. The test thus enables a 
simple communication path between 
two or more nodes to be set up. 

The applications software is specific 
to the particular role performed by the 
microcontroller or computer in the net- 
work. It therefore depends on what 
the station is going to be used for: log- 
ging of measurements; driving a dis- 
play; transferring times and dates; and 
others. 

Each node therefore needs its own 
particular software appropriate to its 
function. The sum of all the functions 
carried out by the various stations is 
the desired overall function of the net- 
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Table 6. Internal SFRs in 
the controller used in 
the basic CAN mode. 


work. In other words, 

the spatially distrib- 

uted network can be controlled, driven 
and monitored to arrive at the final 
result. 


OPERATING SOFTWARE 

The programming of the CAN con- 

troller is subject to the same general 

principles as that of other external 
peripheral units. 

e The function of the controller is 
fixed or set by programming sets of 
data by internal Special Function 
Registers (SFR). 

e These internal SFRs are interpreted 
by the microcontroller or computer 
as normal memory addresses in the 
external RAM range, to which data 
can be written or from which data 
can be read. This means that the 
microcontroller or computer is not 
aware that it is operating in con- 
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junction with a CAN 

controller. Only access 
to specific memory locations is 
determinative for it as well as for 
the applications software. 


When, therefore, the applications soft- 
ware for controller IC3 is being pro- 
duced, the following points should be 
Clarified or processed. 

e Set the chip-select base address for 
the SJA1000 controller. 

e Understand the internal setup of 
the structure of the SFRs in the con- 
troller. 

e Create the routine for the basic ini- 
tialization of the controller. 

e Create the routine for applying 
data to the CAN bus. 

e Create the routine for receiving 
data from the CAN bus. 


The processing of relevant points for 
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the basic CAN mode of the controller 
is looked at in some detail in the fol- 
lowing paragraphs. Extensive and 
more detailed information can be 
found in the data sheets and applica- 
tion notes for the controller (see Ref- 
erence at end of this article). 


SETTING THE CHIP- 
SELECT BASE 
ADDRESS 
The chip is accessed via the chip-select 
base address. Since controller 1C3 in 
the basic CAN mode needs a coherent 
external address range of 32 bytes, and 
in the PaiCAN mode one of 128 bytes, 
the maximum range is set at 128 bytes 
so as not to preclude the use of the Pd- 
iCAN mode in future operations. 
The SJA1000 controller is enabled 
by alow levd at its CS terminal (pin 3). 
This means that the microcontroller or 
computer must construct its address 
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start of initialization or 
reconfiguration 


disable CAN interrupt source in the 
host controller 
enter reset mode/request 


reset mode/request = 
reset/present? 






configure clock divider register: 
1. PeliCAN or BasicCAN 
2. CAN input comparator bypass 
3. CLK OUT control and frequency 
4. usage of TX1 


configure acceptance code and 
mask reaisters 
configure bus timing registers 
configure output control register 


enter operating/normal mode 


reset mode/request 
= normal/absent? 










if used: enable CAN interrupts, 
enable CAN interrupt source in the 
host controller 


end of configuration 
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Figure 13. Flow dia- 
gram for use when the 
CAN controller is to be 
initialized. 


coding in such a way that within a 
coherent address range of not fewer 
than 128bytes a low signal is pro- 
duced at pin 8 of connector K3 to 
enable the data transfer to be carried 
out by the CAN controller. The first 
address at which this is the case 
becomes the so-called chip-select base 
address of the controller. When the 
microcontroller or computer accesses 
a random memory location in this 
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address range, it receives the byte con- 
tent of an SFR in the controller or it 
can write a byte-word in an SFR of the 
controller. 

In the following it is assumed that 
the chip-select base address of the 
SJA1000 controller is FOOOH. 


INTERNAL STRUCTURE 

OF AN SFR 

The determinant SFRs of controller 
1C3 for operation in the basic CAN 
mode are shown in Table 6. The mean- 
ing of the various columns is as fol- 
lows. 


1. The first column, CAN address, 
gives the internal addresses of the rel- 
evant SFRs, to which only the chip- 
select base address of the IC needs to 
be added. If, for instance, the status 
register of the controller is to be 
accessed, FOOOH must be added to the 
internal address of the SFR, which is 2. 
If, therefore, a read or write operation 
on the register is desired, the software 
must be programmed to enable the 
external RAM location to be accessed 
with address FOO2H. The Clock 
Divider Register is from then on acces- 
sible at address FOLFH (=F000H +31D 
- note the use of different number sys- 
tems). 


2. The second column shows the basic 
division of the SFRs into three differ- 
ent groups: the control group, the 
transmit buffer group, and the receiver 
buffer group. 

3. The controller supports two soft- 
ware-controlled modes: 


e Operating mode, which is the nor- 
mal mode of operation; 

e Reset mode, which is the mode IC3 
is in when it is dearing a hardware 
reset or when the reset bit in the 
control register is set. The controller 
then reverts to the normal operat- 
ing mode. 


The reset mode is necessary when 
the controller is to be (re)initialized, 
that is, certain operating parameters 
can be set only in the reset mode. The 
reset bit is then set (the controller sets 
its normal operating mode), where- 
upon the relevant parameters can be 
altered, after which the reset bit is dis- 
abled. After that, the controller 
resumes operation with the altered 
parameters. 


4. Columns 4 and 5 show 

e the functions of the register; 

e the meaning of the contents when 
the register is read; 

e the meaning of the contents when 
the register is written to in the 
operating mode. 


5. Columns 5 and 6 show the relevant 


data for the register in the reset mode. 
Hereis an example of an internal SFR 
with address 4. 
Operating mode (normal operation of 
the controller): 


e Read - although reading the regis- 
ter is possible, there are no usable 
results since the read-out value is 
always FFH. 

e Write: the register cannot be writ- 
ten to. 


Reset mode (the controller is in the 

reset state). 

e Read: reading the register gives the 
value of the acceptance code. 

e Write: a new acceptance code can 
be written into the register. 


This example shows that during nor- 
mal operation of the controller this 
SFR has no special function. Note, 
however, that in the reset mode the 
acceptance code with which the con- 
troller functions during normal opera- 
tion is set. 


CREATING THE 
ROUTINE FOR BASIC 
INITIALIZATION 

Before work on this routine is begun, 
a dose look at the Application Note for 
the SJA1000 controller (AN 97076 - see 
Reference) is highly advisable. On 
page 23 of this document, the manu- 
facturers give a flow diagram with 
detailed comments on how the initial- 
ization of the controller should be pro- 
ceeded with (see Figure 13). 

Another close look at the descrip- 
tion of a single register should then 
enable the values of the parameters to 
be set readily to individual require- 
ments and wishes. 


CREATING THE 
ROUTINE FOR 

SENDING DATA 

As mentioned earlier, CAN controller 
type SJA1000 assumes most of the 
tasks involved in sending data. The 
sending of byte data onto the CAN 
bus requires only four actions. 


e Delivery to the controller of the 
wanted identifier (ID) for the frame 
to be transmitted. 

e Indicating how many data bytes 
are to be sent (0-8). 

e Determining whether the frame is 
a remote transmission request 
(RTR) frame or not. 

e Writing the wanted data bytes to 
the send data buffer of the con- 
troller. 


That’s all! The remainder of the 
process is carried out automatically by 
the CAN controller, that is: 

e assembling the frame; 

e calculation of the CRC sum; 
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e allocation of the other fields in the 
frame; 

e accessing the bus; 

e transmitting the frame; 

e checking for errors; 

and so on. 


Messages indicating whether the 
transmission was successful or not are 
returned to the user via the Status reg- 
ister to enable action to be taken as 
appropriate. 


CREATING THE 
ROUTINE FOR 
RECEIVING DATA 

In the reception of data, CAN con- 
troller types SJA1000 again takes on 
most of the necessary actions, that is, 
data are received almost wholly auto- 
matically by the controller. The con- 
troller processes the received frames 
and writes the wanted information 
contained in them to the error detec- 
tion section and acceptance filter in its 
RXFIFO (=receiver first in first out 
memory) - see Figure 14. 

If the acceptance filter is switched 
off, each received frame is evaluated. 
In the RXFIFO, the following data 
from each frame are stored (see 
Table 6, address range 20-29): 


e frame identifier; 

e remote transmission request (RTR) 
bit; 

e data length code (DLC); 

e useful data bytes. 


As the range of the internal RXFIFO in 
IC3 is exactly 64 bytes, the number of 
frames that can be stored in the inter- 
mediate memory depends on the 
length of the frame, and more partic- 
ularly on the data length code. 

The receiver buffer window (see 
Table 6, addresses 20-29) that can be 
read by a user is what is shifted by the 
RXFIFO to the window. This consists 
of an actually received set of data 
(frame or message), which can be 
processed by the user via software. 

Communication between the 
SJA1000 and the microcontroller or 
computer in the receive mode may 
take two forms. 


e Interrupt-driven. When the con- 
troller has received a complete and 
error-free frame, it initiates an inter- 
rupt in the microcontroller via its 
pin 16 (INT). This causes the micro- 
controller/computer to react imme- 
diately to the received message so 
that this can be read without delay 
via the controller. 

e Polling* operation. In this kind of 
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Figure 14. Structure of 
the receiver memory 


/ buffer 
et command 
incoming 4 
messages __-* 
4 
oe 
operation, the | range. 


receiver buffer sta- 

tus bit in the status 

register of the controller is continu- 
ously interrogated by the micro- 
controller/computer. When this is 
set - indicating that the controller 
has received at least one message 
correctly - the software reads this 
frame and processes it as relevant. 


When a message has been read, the 
applications software reenables the 
receiver buffer window to acknowl- 
edge that the earlier message passed 
to it has been processed. The window 
is then ready to receive the next frame 
from the RXFIFO. In this way, the 
applications software ensures that one 
frame after another is processed. 

There are two further matters to be 
noted. 


e Immediately after a frame (mes- 
sage) has been read and processed, 
the receiver buffer window must be 
released by a ‘rdease receiver buffer 
command’ so that the controller 
can shift the next message to the 
window. If this command is not 
given, the same message is 
processed again and again, which 
causes the RXFIFO to overflow 
since other received frames are not 
being shifted. 

e When a high frame rate is used, 
that is, when the data transfer rate 
is high or many messages are sent 
one after another, there is a risk of 
the RXFIFO overflowing rapidly if 
the messages are not shifted read- 
ily. If such situations are likely to 
occur, a sufficiently powerful micro- 


controller or computer 

must be used in associ- 

ation with high-quality 
software. 


When an overflow of the RXFIFO 
occurs, the controller indicates this by 
setting an error-bit, that is, a Data 
Overrun Status bit in the status regis- 
ter. The relevant message, which is 
just about to be shifted into the 
RXFIFO (and which caused the over- 
flow) is then erased and lost. 
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Only part of the software needs to be pro- 
grammed by the constructor, since in next 
month's issue a complete applications pro- 
gram in Pascal will be published which 
enables all basic functions of the CAN bus 
to be tried and tested. The suggested micro- 
controller is a Type 80C537. Apart from the 
80C537 used in the single board compan- 
der published in the] une 1997 issue of this 
magazine, there is now a smaller, less 
expensive version of this SingleBoard 
Computer (SBC) available. This version 
will be highlighted in next month’s issue 
under the title ‘537-Lite Computer’. 


Reference: 

CAN bus controller and transceiver mod- 
ules (Philips Semiconductors) 

www us.semiconductors.philips.com/can/ 
www-us.semiconductors.philips.com/ can 
/support 





* Polling is a form of time division multiplexing. It is a process by which one node (primary station) in a network can address any other 


node (secondary station), giving the secondary node access to the communication channel. 
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